\section{Erlang Virtual Machine Implementations}
Erlang's execution process is quite similar to any virtual machine oriented programming languages. A compiler compiles Erlang source code to Erlang bytecode which is then interpreted in an emulator. Using the HiPE compiler it is also possible to compile Erlang source code directly to native machine code. Native code can then be combined with emulated code using the HiPE runtime system. 

Since the early days of Erlang two implementations of Erlang Virtual Machine have existed \textbf {Joe's Abstract Machine (JAM)} \cite{jam} and \textbf{Bogdan/Björn's Erlang Abstract Machine (BEAM)}. JAM was the original Erlang virtual machine, inspired by the (Prolog) WAM (Warren's Abstract Machine). 

\subsection {JAM}
JAM utilized a Stack based virtual machine much like java whereby arguments to functions are passed by explicitly pushing them on the stack and then jumping to the first instruction for the function. JAM's main purpose was to bootstrap the Erlang development process.
\subsection{BEAM}
BEAM is the current de-facto implementation of the Erlang system. BEAM was initially an attempt to compile Erlang via C \cite{beamc}. It made heavy use of named macros functionality of GCC. It was abandoned after benchmarking showed that the resulting code was only faster than VM-based Erlang for small programs \cite{faq}. In contrast to JAM, BEAM is a virtual register machine whereby virtual machine registers are used for function calls and parameter passing.	 

\subsection {Function execution in JAM and BEAM}
Figure~\ref{fig:bytecode} shows the bytecode generated by the different VMs for the factorial program. 
The overloaded function definitions are referred to as clauses. The function to be executed is semantically based on pattern matching. When for e.g. \textit {factorial(4)} is called first the clause \textit{factorial(0)} is considered, if that doesn't match then the other clause factorial(N) (where N refers to any value is matched), which results in that function being executed. In case of no match an error is thrown. In terms of bytecode BEAM and JAM implement it differently. BEAM uses the register x register to pass a single argument and x(0) refers to the first argument.The \textit{test, is\_eq\_exact} instruction implements the pattern match by comparing if x(0) is equal to 0. In case is\_eq\_exact is true it proceeds to execute the next instruction otherwise it jumps to the label identified by \textit{(f,3)} i.e. label 3 where the N*factorial(N-1) clause is executed. In this clause after the memory allocation for N, a built in function is used to execute the subtraction "N-1" and the result is stored in x(1) register. After that in order to setup to call \textit{factorial(N-1)} x(0) is backed up into y(0) register and then x(1) is moved into x(0) thus, setting up the registers for calling factorial with argument N-1. After \textit{factorial(N-1)} returns, a built in function is executed to multiple y(0) (which is holding N) with x(0) which holds the return value from \textit{factorial(N-1)}. The result of this gets stored into x(0) which becomes the return value.

In case of JAM the instruction \textit{try\_me\_else,label\_1} is generated corresponding to \textit{factorial(0)} clause. The semantics of this instruction are to try and execute the following instructions but in case of any failure go to label 1 which is the other clause. In case of factorial(0) clause the \textit{arg,0} pushes the first argument onto the stack and then getInt compares the top of the stack to zero. In case top of the stack isn't zero it causes a failure which results in control moving to label 1 where execution continues. Before moving to label 1 the stack is restored.
\begin{figure*}[t]
\begin{minipage}[t]{\columnwidth}
\centering
\psfig{figure=figures/bytecode.pdf,width=5in}
\caption{Bytecode generation by JAM and BEAM}
\label{fig:bytecode}
\end{minipage}
\hfill
\end{figure*}

\subsection{High Performance Erlang (HiPE) }
HiPE was initiated as a project to  develop a just in time native compiler for Erlang \cite{hipeinit}. It was based on JAM and although it outperformed both JAM and BEAM for small benchmarks \cite{hipeinit}, it had problems scaling up to compile large systems (e.g., tens of thousands of lines of code) and since it was implemented in C, it was difficult to rapidly develop and debug new optimizations in it. Thus, it was decided to implement the HiPE compiler in Erlang itself.

The current HiPE system allows for native code compilation and execution by a two pronged approach. It provides an Erlang to native compiler that can be used to generate native code for specific functions and not just whole modules, which are the conventional Erlang compilation units. In addition it provides a runtime system that handles intermixing of native and emulated functions. The intermixing takes care of hot code reloading and also allows for Erlang's per process generational garbage collection. Although, the current system is tightly coupled with BEAM, it can also be used with the JAM machine. Figure~\ref{fig:hipe} illustrates the architecture of the HiPE system.
\begin{figure*}[t]
\begin{minipage}[t]{\columnwidth}
\centering
\psfig{figure=figures/hipe.pdf,width=3.1in,height=2.5in}
\caption{HiPE Architecture}
\label{fig:hipe}
\end{minipage}
\hfill
\end{figure*}

\subsubsection{HiPE Compilation Process}
The Erlang/OTP compiler first performs macro preprocessing, parsing, and some de-sugaring (e.g., expanding uses of the record syntax) of the Erlang source code. After that, the code is rewritten into Core Erlang. Various optimizations such as constant folding, and (optional) function inlining, are performed on the Core Erlang level. After this, the code is again rewritten into BEAM virtual machine code, and some further optimizations are done. The HiPE compiler has traditionally started from the BEAM virtual machine code generated by the Erlang/OTP compiler. The BEAM code for a single function is first translated to ICode, an assembly-like language with a highlevel functional semantics. After optimizations, the ICode is translated to RTL ("register-transfer language"), a low-level RISC-like assembly language. It is during this translation that most Erlang operations are translated to machine-level operations. After optimizations, the RTL code is translated by the backend to actual machine code. It is during this translation that the many temporary variables used in the RTL code are mapped to the hardware registers and the runtime stack. Finally, the code is loaded into the runtime system. 

HiPE has extended the Erlang/OTP runtime system to associate native code with functions and closures. At any given point, a process is executing either in BEAM code or in native code: this is called the mode of the process. A mode switch occurs whenever control transfers from code in one mode to code in the other mode, for instance when a BEAM-code function calls a native-code function, or when the native-code function returns to its BEAM-code caller. The runtime system handles this transparently, so it is not visible to users, except that the native code generally executes faster.
